[Vorherige]
[Nächste]
[Index]
comp.sys.apollo Apollo Frequently Asked Questions (FAQ) part [2/3]
- Subject: comp.sys.apollo Apollo Frequently Asked Questions (FAQ)
part [2/3]
- From: ahn@wfu.edu (Dave Ahn)
- Date: 20 Dec 1994 21:42:51 GMT
- Newsgroups: comp.sys.apollo,
comp.answers, news.answers
- Summary: This posting contains a list of Frequently Asked
Questions and their answers about Apollo Domain series computers.
Archive-name: apollo-faq/part2
Archive-location: ftp://ftp.wfu.edu/usenet/apollo/FAQ
Posting-Frequency: monthly
Last-modified: Tue, 4 Oct 1994
Version: 5
Keywords: FAQ, Apollo, Domain/OS
---------------------------------
[4.14] How can I get my printer to work?
---------------------------------
It's not as easy as it should be. If you want BSD (lpr/lpd) printing, then
see the separate file "printing," available in:
ftp://archive.umich.edu/pub/apollo/printing
ftp://ftp.eb.ele.tue.nl/pub/apollo/notes/printing
If you want to use Apollo (prf/prsvr/prmgr) printing, in particular if you
want to use a dot-matrix or other unsupported printer, then see the
"generic" driver and related comments. These files are available in:
ftp://maths.su.oz.au/print_driver.README
ftp://maths.su.oz.au/print_driver.tar.Z
ftp://ftp.eb.ele.tue.nl/pub/apollo/print/print_driver.README
ftp://ftp.eb.ele.tue.nl/pub/apollo/print/print_driver.tar.Z
--( 2/15/94, Paul Szabo <szabo_p@maths.su.oz.au> )
---------------------------------------------------------
[4.15] Why do I get "cannot start daemon" when I try to use lpr?
How do I get BSD style lpr/lpd to work?
---------------------------------------------------------
The Apollo lpr/lpd seems to differ from other BSDs in that it apparently
references the Domain name (set by ctnode) as well as servername (created in
/usr/spool/lpd by the system administrator). Those names should agree with
the Internet hostname. The hostname is set by default to the Domain name
(which by default is set to the hard disk name, I think, as Yan Lau
suggested in his note on how they resolved this problem). IF YOU MODIFY
rc.local TO EXPLICITLY SET THE HOSTNAME (IGNORING THE SAGE ADVICE IN THE
COMMENTS THERE), THEN LPR/LPD WILL NOT SPAWN NEW DAEMONS. The best
solution might be to get the lpr/lpd sources and recompile, but the easiest
solution seems to be:
uctnode <your old node name>
lcnode -me (get your node number)
ctnode <internet hostname you want to be> <your node #>
* Then be sure the lines in rc.local that set hostname are commented out so
the hostname will be the Domain node name
* Then be sure that /usr/spool/lpd/servername contains the same name as the
Domain name (hostname > /usr/spool/lpd/servername)
* Then carefully check the protections on lpr, lpd, and the various spool
directories as suggested in earlier notes on this problem.
Of course, look in the BSD Systems Admin guide for other aspects of the
setup such as printcap entries, etc. This approach has the advantage that
it doesn't require modifying sendmail.cf to handle Internet mail, etc. (the
"I refuse to talk to myself" problem that started all of this!).
--( 2/15/94, David Todd <hdtodd@eagle.wesleyan.edu>
I have just been through the exercise of setting up (BSD) lpd, to allow
BSD-to-prf printing. I hope these notes will help others to do the same.
You need to set up your /etc/hosts.lpd file to allow other hosts to connect
to your lpd. Note that contrary to what is said in the file 'printing'
referenced in the FAQ, you should not put these names in any /.rhosts or
/etc/hosts.equiv files (lpd does its own checking, not using rsh; unless of
course you also want to allow rsh/rogin access and live dangerously).
The manuals, and the FAQ file, tell you to create a file
/usr/spool/lpd/servername containing the full, expanded TCP/IP name of the
node; and maybe even set the AEGIS (ctnode) name of the node to this same
name. What I found to work best is to put the AEGIS name of the node in the
file /usr/spool/lpd/servername. However, lpd will not start with the file in
place (I could not get lpd to tell me why). What I did was modify /etc/rc to
have something like:
/bin/rm -f /usr/spool/lpd/servername
/usr/lib/lpd
(echo "$NODENAME" > /usr/spool/lpd/servername)
Then I do not have any of the "cannot start daemon" problems, and do not
care that adder.maths.su.oz.au is really //c640g.
I wanted BSD-to-prf printing. My /etc/printcap file is something like:
# These entries spool files via the prf command (invoked from
# /usr/lib/lpfilter). They work for ANY file (ASCII text or
# postscript), as prf handles them both.
aolw|Applied Office Apple LaserWriter:\
:lp=/dev/null:\
:sd=/usr/spool/lpd/all:\
:sf:sh:\
:if=/usr/lib/lpfilter:\
:lf=/dev/null:\
:mc#1:sc:\
:mx#1000:
with (except for the name) identical entries for the other printers. My
/usr/lib/lpfilter file contains:
#!/bin/ksh -
# Filter to use with lpd: will print file with prf.
#
function mess
# Put message in log file.
{
print -R "$(/bin/date) $*: <$USR> <$HST> <$PRT> <$FIL>" >> \
/usr/adm/lpd.log
case "$1" in Bad* ) exit 0;; esac
}
#
USR=
HST=
FIL=
PRT=
#
while [ $# -gt 1 ]; do
case "$1" in
-n ) USR="$2"; shift;;
-h ) HST="$2"; shift;;
-J ) FIL="$2"; shift;;
-p ) PRT="$2"; shift;;
esac
shift
done
#
case "$USR" in '' | *[!a-zA-Z0-9._]* ) mess 'Bad username';; esac
case "$HST" in '' | *[!a-zA-Z0-9._]* ) mess 'Bad hostname';; esac
case "$PRT" in '' | *[!a-z0-9]* ) mess 'Bad printer' ;; esac
#
mess 'Printing'
/bin/rm -f /tmp/print.u
/usr/apollo/bin/prf -check -printer "$PRT" -user \
"$USR@${HST%.maths.su.oz.au}" /bin/rm -f /tmp/print.u
Hope this will help someone.
--( 3/17/94, Paul Szabo <szabo_p@maths.su.oz.au> )--
--------------------------------------------------------------------
[4.16] Why do I get:
Unable to go into maintenance state. User not authorized to
perform operation (network computing system/Registry Server)
How can I back up the registry?
--------------------------------------------------------------------
I use a cron to run a script as user root on a regular basis to backup the
registry. I have been checking the log file recently and every time the
following error message appears:
Unable to go into maintenance state. User not authorized to
perform operation (network computing system/Registry Server)
Any ideas?
--( 2/15/94, Robin Brown <robinb@resmel.bhp.com.au> )
The registry service is a distributed application that uses an encryption
based authentication algorithm. This means that breaking security on a
single machine does not allow you to attack the registry database - you
have to have access to an administrator's password in order to perform
updates on the registry.
One workaround for the problem you are having is to make sure that cron is
running as the real "root" user. To do this, don't run cron from the
/etc/rc script. Instead, login as root and then run cron in the background
(I believe that the command "/etc/server -p /etc/cron" will protect the cron
process from termination when root logs out.) Don't forget the "-p"
option - this preserves the current user's identity. If you leave this out,
cron will run as user.none.none and will not be able to perform its normal
tasks.
You need only do this on the machine that is responsible for performing
routine backups for the registry database. All other machines can start
cron in the normal way.
Future distributed systems will have this behavior for most services. For
example, the OSF DCE (Distributed Computing Environment) uses authentication
protocols for all distributed accesses (including access to files on non-
local machines). Fortunately these systems come with better mechanisms for
running batch jobs from cron (unlike the "hack" I describe above).
--( 2/15/94, Joe Pato <pato@apollo.hp.com> )
-----------------------------------------------------
[4.17] How do I find out about and fix bad spots on my disk?
-----------------------------------------------------
I always use fixvol to reformat the track the bad spot is on. If you would
rather just move the block into the badspot list, here's an excellent
description of the problem and fix, from Paul Szabo:
--( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )
This article describes how to get rid of bad blocks on disks. Bad blocks
will naturally develop during the useful life of the disk. There is no
cause for alarm as long as the total number or the rate of growth of bad
blocks is not excessive.
Once these bad blocks develop, they should be avoided (i.e. should not be
used). While the problems are intermittent or recoverable, you may be
inclined to put up with the problem. But bad blocks usually deteriorate,
and may cause your node to crash. (Our DN10000 developed a bad block in a
directory, and any access to this directory sometimes caused it to crash.)
Simply, you need to add the block numbers to the bad spot list using INVOL.
If you are happy to wipe the disk and start from scratch, everything is
easy. Run EX DEX, RUN WIN (no defaults, all disk: start 0, end last
address, write enabled) and this will tell you about every single bad
block. Add these to the bad spot list using INVOL, re-format the disk, and
install the OS. There is no need to go to this extreme, however.
Get a listing of problem blocks using /systest/ssr_util/lsyserr. You should
use this periodically to monitor the behaviour of the disk. Look for
repeated problems with disk blocks; you may want to skip the once-only
problems. Use the physical disk addresses. (In case of striped disks, ignore
the RELATIVE addresses. Run the output of lsyserr through "grep 'Phys daddr
=' | sort | uniq -c".) You could also run EX DEX, RUN WIN -ENTIRE. This will
read all your disk (without re-formatting or writing it).
You may simply tell INVOL about the bad block addresses, and then run SALVOL
to fix up the disk. This seems to work reasonably well, but then ... do you
trust them (or any other Apollo utility :-) to work properly? (Note that
SALVOL occasionally uses addresses relative to a logical volume, these are
one smaller than the physical addresses. Then again, the discrepancy is
sometimes not one but two... this may be related to a physical volume PV
label on each of our striped disks.)
To give you confidence in what you are doing, you would like to know what
files are at those disk addresses.
You may use /systest/ssr_util/rwvol (select READ, enter DADDR, then just
[RETURN] for start and end) to display UIDs of objects, then
/systest/ssr_util/upath to display pathnames.
Probably it is easier to use /systest/ssr_util/fixvol (this has online
help, type help). Use the read command to display UIDs/pathnames:
(fv [p])> r 12345
uid: 478771C7.3001A581 /y/sfw/reduce3.3/fasl/int.b
page: 9
dtm: 478774A5 Wednesday, December 20, 1989 11:40:12 am (EST)
blk_type: 0
sys_type: 0 (file_$file_type)
pad: 00000000 00000000
checksum: 0000
daddr: 12345 ( 163- 1- 0) disk# 1
Now that you know the pathname, you may wish to move it somewhere 'out of
the way' and copy it back to its proper place /bin/mv file /lost+found
/bin/cp -pPiov /lost+found/file dir This may not be necessary, but it is
cheap insurance.
It seems to me that you cannot do much about vtoce blocks:
(fv [p])> r 1234
uid: 202.00000000 vtoc_$uid
page: 1232
dtm: 4AF72F18 Wednesday, June 13, 1990 9:53:49 am (EST)
blk_type: 0
sys_type: 0 (file_$file_type)
pad: 00000000 00000000
checksum: 0000
daddr: 1234 ( 16- 2- C) disk# 0
BEWARE: if the bad blocks are in the vtoc, then SALVOL may not be able to
fix up your disk, in which case you will have to wipe it and start from
scratch.
You are now ready to tell INVOL about the bad blocks.
Run SALVOL to fix the disk. SALVOL will find 'multiply allocated blocks'
(since they are also in the bad block list), and then go into 'second pass'
looking for these multiply allocated blocks. SALVOL will report to fix some
objects with the correct names, but for others it will report to repair
objects at 'vtocx = something' (when the block is not at the beginning of
the file?). It will attempt to copy the bad block somewhere else, and
usually it will succeed.
There is one problem with SALVOL. If the bad block is in a directory, SALVOL
will orphan the files catalogued there; but as it succeeds in copying the
bad block, the files will still be catalogued in the original directory.
When you boot the node, find_orphans will catalogue these files in
/lost+found, but the reference count (number of hard links) will be wrong
(one instead of two). If you remove the file pointed to by /lost+found,
then when listing the original directory you get the message 'object not
found'. Admittedly, SALVOL at the end of its run said '... errors ...
require that Salvol be run again ...' which I did, but that did not seem to
do anything. Maybe it needed find_orphans between the two runs. Anyway, I
made another copy of the files...
Appendix
The only manual I have on the workings of SALVOL is rather old: 'DOMAIN
System Utilities', part no. 009414 Rev 00, Sept 1986. Some quotes from this
manual below. (The newer 'Domain Hardware Utilities Reference', part no.
014881-A00, barely describes how to use SALVOL.)
Classes of errors: ... 4. Multiply allocated blocks... allocated to more
than one file, or to a file and to a system structure, such as the VTOC,
the BAT or the badspot list....
The salvager attempts to repair multiply allocated blocks... if the salvager
finds a multiply allocated block and can determine which file the block
belongs to, then it sets the trouble flag only for the non-owning file.
DOMAIN disk volumes are structured so that naming directories and
space/location information (in a VTOC) about files are kept separately.
Currently, the salvager does not synchronize these on-disk structures. ...
cannot detect orphans...
I/O errors that occur on physical and logical volume labels or on the block
availability table (BAT) are fatal to the salvager. All other errors are
reported, but are non-fatal.
Generally, the salvager always repairs the BAT (except in the case of hard
I/O errors) and the VTOC. Thus, if AEGIS badly malfunctions, writing normal
file blocks over the BAT or the VTOC blocks, for example, the salvager
repairs the BAT or VTOC and the file. To do so, it copies the data into a
newly allocated block and reinitializes the overwritten block.
If a block is multiply allocated to both the badspot list and to a file or a
VTOC chain, the salvager tries to copy any potentially valid data to a newly
allocated block. If the block is in the badspot list because of persistent
device level errors, however, the copy may fail; the salvager then prompts
for alternatives. The salvager and badspot listing cannot be used to correct
persistent errors in the BAT or VTOC hash space, however. The salvager
aborts in the former case, and simply reports the I/O error in the second
case. The only solution is to reinitialize the volume around such badspots
using INVOL.
--( 2/15/94, Paul Szabo <szabo_p@maths.su.oz.au> )
--------------------------------------------------------------------
[4.18] What do I need to emulate a PC on my Apollo? What is DPCC, DPCE and
DPCI?
--------------------------------------------------------------------
A company called MicroMechanics in Cambridge, MA, has acquired the rights to
manufacture, distribute, and support the PC coprocessor (DPPC), the PC
emulator (DPCE), and the PC integration (DPCI) products for Domain/OS. The
founders were involved in the initial DPCC development. For further
information, contact:
MicroMechanics
84 Sherman Street
Cambridge, MA 02140
Tel. (617) 868-1899 FAX
(617) 876-5950
Net: umech!ljohnson@uunet.uu.net
--( 2/15/94 )
-------------------------------------------------------------------
[4.19] How do I prevent a system hang when booting while preserving editor
files?
-------------------------------------------------------------------
>Another "opportunity for excellence" awaits. I am currently experiencing
>problems with the "preserve" function. Whenever I reboot a workstation
>(OS 10.3.5.4 and 10.4) and there are files to be preserved (so to speak)
>the machine "hangs" at the "Preserving Editor Files" message. I usually
>have to crash the machine, set to service mode, salvage, get to Phase II
>and delete files in tmp and /usr/preserve directories before bringing the
>machine up. I figure this is a permission problem of some sort, but how
>do I fix. I did not see this in the FAQ.
--( 2/15/94, Kenneth Lee Atchinson <edsverk@ed4000-2.lerc.nasa.gov> )
This is another result of Domain/OS not being real UNIX--preserve is trying
to mail each user who has ed/ex/vi files left a notice of what was left at
the time of the crash and how to recover it. However, neither the registry
nor tcp is available, so sendmail hangs trying to deliver the mail, which
hangs your boot since the preserve waits for its children to complete (so
/tmp can be cleaned safely). Your solution is the only way out once it
happens; I have disabled the 'preserve' step in /etc/rc so it doesn't get
stuck there (just comment it off). Another solution would be to do the
preserve later (and the /tmp cleaning too), but then you must be quite
careful about what is deleted, as some files belonging to boot processes
will probably exist by that point.
--( 2/15/94, Mike Peterson <system@alchemy.chem.utoronto.ca> )
-----------------------------------
[4.20] How can I do postscript accounting?
-----------------------------------
If you run prmgr/prsvr/prf to PostScript printers and want to know who is
printing how many pages, then this is for you.
My audit_filter package is available from ftp://maths.su.oz.au/print
(129.78.68.2), and
ftp://ftp.eb.ele.tue.nl/pub/apollo/print/audit_filter.tar.Z .
The file audit_filter.README is included below, as well as the README file
for the generic printer driver which is available from the same sites.
Audit filter, version 1.0, dated 14 Sep 93
audit.c is an audit filter. It is for use with the Apollo prf/prsvr/prmgr
with the postscript printer driver, and is compatible with SR10.4 only. It
shows the number of pages printed in each job, and aids somewhat in
detecting attempts to avoid accounting.
To compile/install the filter simply execute the INSTALL script.
Suggestions are welcome. For further information, please contact the author:
(Standard copyright and disclaimers apply.)
--( 2/15/94, Paul Szabo <szabo_p@maths.su.oz.au> )
-------------------------------------------
[4.21] How can I keep my node clocks synchronized?
-------------------------------------------
Use xntp, available from the usual ftp sites. See the file Readme.xntp for
Apollo patches. See date.tar.Z for a simple program that just sets one
node's clock from another node's clock.
[Note: these files are on Jim Rees' archive: apollo.archive.umich.edu ]
--( 2/15/94, Jim Rees <Jim.Rees@umich.edu> )
Timed works well on SR10.2-nodes (it did not work in SR10.1).
We start it from rc.local as follows:
/etc/timed -M -n <name of the local network>
and we list this local network in /etc/networks. This works well for
synchronizing the clocks among all Apollos in the local network.
Recently, we wanted to synchronize the clocks with the outside world also
(i.e. other workstations in our department). Our Apollos are connected
through a token ring, but one of them has an Ethernet card and runs routed
to provide the connection to the outside world. On this machine we do the
following:
/etc/timed -M
The other ones still listen only to the local network, and do not attempt to
become master anymore:
/etc/timed -n <name of the local network>
This implies that when booting our Apollos the "master machine" must go
first. Timed only accepts corrections from the timed on another machine if
they are not "too extreme". In the latter case set the clocks manually using
/bin/date once before starting the time daemons. If you set a clock
backwards, don't do it with /bin/date, but shut the node down, use:
>EX CALENDAR
to set date and time, and wait for the amount of time that you had set the
clocks backwards before rebooting. This avoids duplicate time stamps.
For all this to work correcty, TCP/IP has to be installed properly.
--( 2/15/94, Annegret Liebers <annegret@combi.math.tu-berlin.de> )
You may be interested in the "-a" option added to sr10.4 timed. It specifies
that the master rules the network, with no democratic input from the other
nodes, and thus it's irrelevant when it boots.
--( 2/15/94, Robert Stanzel <rps@apollo.hp.com> )
-----------------------------------------------------------------
[4.22] I can't get my rgyd or registry database to work. What can I do?
-----------------------------------------------------------------
If you're experiencing problems starting the master rgyd or creating a
registry database, the following information should help.
There are a few things that must happen for the node to see your master
registry. You MUST have a local location broker daemon running. You will
either have an llbd or rpcd running as your local location broker. Since
this node was brought into your domain, and I assume you did not re-build
it, you must copy the "glb_obj.txt" file from your MASTER GLOBAL LOCATION
BROKER node. Kill your llbd or rpcd process on your new node. To find
your master glbd, run the "drm_admin" command on another node. Do a man
page to get command info. The glb_obj.txt file is located in the /etc/ncs
directory. Copy it to your new node in the same location. Make sure that
a stub exists in the /etc/daemons directory to start the rpcd or llbd
process. Now, this is a trick I got from the HP HOTLINE. Delete the file
"/sys/node_data/etc/.rgyloc" and rename "/sys/node_data/hint_file" to
"/sys/node_data/hint_file.old". Shut the node down and reboot. The system
should come up seeing your master registry and print manager. Also,
remember to update your root directories on ALL nodes "ctnode -update".
The master registry node must know about the new node's "name" either it be
//node_HEXCODE or //"name", AND the new node must know about the other nodes
as well. **Make sure you do this BEFORE you reboot the node.**
--( 7/28/94, John Stephens <stephens@lobby.ti.com> )--
You should do some tests: Look in /sys/node_data and check if the files
glb. ... exist. Then you should check if the rgy is working: start
'/etc/rgy_admin' see the result and type 'lrep -st' at the rgy_admin
prompt. If all works fine you should see something like
# /etc/rgy_admin
Default object: rgy default host: dds://chh
State: in service master replica list is writable
rgy_admin: lrep -state
(master) dds://chh state: in service 1994/06/11.14:28:35
If you see another result the registry is not working correct. If the
default host is not specified you could do it. See the on-line help. If
you see something like 'registry service unavailable' then you your rgyd is
not working properly. Stop the rgyd if it is running and restart with the
option 'recreate'. Try also with edrgy to add a new user. You can add one
only if all works correct. Next you start '/etc/ncs/lb_admin. An Domain
Dialog interface is opened grow the pad until you see all of it. Look at
the grey field middle-top. Click local or global broker with the left mouse
key, click 'clean' and 'lookup' to see if the broker has really registerd
you registry etc. (BTW you need to work with this tool if for one reason
or other your network printer is not recognized.) If your registry is not
registered then your setup/start of the daemons was wrwong or failed. Exit
by clicking on 'Exit'. Now you 'cd' to /sys/node_data/system_logs. Copy
'glb_log' to 'xxx', the file is in use, you cannot read it if glbd is
running, See if you have a content like
(DRM) 1994/06/01.14:52:16 opening replica.
(DRM) 1994/06/01.14:52:31 replica of object glb opened.
(DRM) 1994/06/03.11:36:53 opening replica.
(DRM) 1994/06/03.11:37:10 replica of object glb opened.
If you see errors like
(DRM) 1994/02/25.14:59:04 [1c010001] unable to open replica of object
glb.
?(GLB) cannot open replica - communications failure (network computing
system/RP C runtime)
(GLB) exiting
then your global broker does not properly work. (Don't forget to rm 'xxx'.)
Therefore you start '/etc/ncs/drm_admin'. If you get the drm-admin prompt
type 'set -o glb -h //<node-name>'. You should see something like
Default object: glb default host: //chh state: in service
Checking clocks of glb replicas
dds://chh 1994/06/13.11:57
You see the managment of NCS is somewhat intricate. I suggest that you
first try to isolate what is going wrong. If you do have a fresh registry
i.e you have not added a lot of users the best is to start from scratch.
Also check the ACls of /etc. I had curious results in the ACls after
different installations of 10.1 - 10.4 ( which could be reproduced by the
German HP staff. *also* until 10.3 there was a bug in updating the
/etc/passwd file. ) If you dont have the admin manuals you can run into
problems. So try first and if you get the registry not running you can
mail direct or call me up.
One extra point : If you try around and you once get a message saying that
the registry is not writable, then use in 'rgy_admin' the option state
-in_maintenance | -not_in_maintenance to put it to work. You use this
option also before making a backup of the /sys/registry tree.
--( 7/28/94, Carl H. Heidrich <chh@chh.ikp.uni-bonn.de> )--
-------------------------------------------------------
[4.23] What does "Returned status (from pm_$init): XXXX" mean?
-------------------------------------------------------
One of our systems here crashed and came back up with the error message:
Returned status (from pm_$init): F0005
after the copyright message and starting all the daemons, etc. LTX begin
the useful people they are suggested reinstalling the OS (this is a
production system, not to mention rgyd, glbd, prmgr master server). Not a
pleasant prospect. I decided to try a few things first. I removed
/etc/ttys and rebooted which brought the system up but without DM so it was
running but with no way to log in. That allowed me to connect from another
system and mess around. I replaced /sys/dm and /sys/spm and /etc/dm_or_spm
and removed and recreated everything in /dev. And when I rebooted
everything worked. So I can't limit it to one particular thing (I was under
time pressure and couldn't afford structured problem solving time) but I
though if anyone else ran into this problem, they would appreciate the info.
--( 7/28/94, Jon Granrose <granrose@scz.ssi1.com> )--
The status code F0005 (see above) means:
object is not locked by this process (OS/File server).
This would tend to mean that some file that the node is trying to use when
starting a new process is still locked by another process, possibly a
zombie. Since you don't know which fix did the trick, it is difficult to
say what the original problem was. If it happens again, I would suggest
booting the node diskless from another node, and using llkob to check the
list of locked objects, after mounting the local disk as a mounted volume.
Anything that is not remote must be junk, in that mode. The ulkob -f
command can sometimes free up such locked objects. If the /dev fix is what
did it, great. /dev is easy to rebuild. If the /sys/dm was the problem, I
would think that the protected subsystem acl's might have become corrupt.
I had that problem a few times, but with different symptoms. Do check the
protected subsystems, as you were mucking around with dm and spm.
--( 7/28/94, Simon Favre <simon@lsil.com> )--
I've occasionally encountered the error message:
Returned status (from pm_$init): ok
when an Apollo boots up and loads the global libraries. I've found two
reasons why this happens. The first is that part of your global libraries
are either corrupt or missing (the files in /lib). The second reason
is that some configuration file in /sys/node_data are corrupt or missing.
The most prominent example of this second reason is an incorrect syntax
in the /etc/rc file. To correct the first problem, you'd have to copy
the /lib/* files from another node or reinstall the OS. To correct
the second problem, simply create a single user shell and edit the
broken files.
--( 7/28/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )--
Another nasty reason for "Returned status (from pm_$init): ok" is a
corrupted or missing /dev/null (eg it might be "unstruct" instead of "null).
You can't get to a single user shell to fix this, but you can do it from
Phase 2:
) wd /dev
) wd ..
) chn dev dev.bad
) cpt
source: /sys/sysdev
destination: dev
options: r
) shut
Reboot - you are running on a criplled /dev/ so some things might fail, but
you should now be able to mkdev a proper /dev directory.
--( 8/5/94, Russell Ayling <rayling@rta.oz.au> )--
[5.0] =============== SYSTEM RELATED HARDWARE ===============
--------------------------------------------------
[5.1] What is the story on adding more disks to my node?
--------------------------------------------------
If you have a DN2500 or the HP9000/4xx boxes, you can add SCSI-1
by simply connecting them to the on-board SCSI port, assigning the
a legal device ID and terminating the chain. This is fairly
straightforward. The 9000/4xx series can have up to about 9GB of
SCSI disk space.
There are several restrictions to adding more disks to a DN[345]xxx box.
If you have an SMS/Omti (8xxx, 11914 model) ESDI floppy/hard drive
controller card, then you can add only up to two disks per node.
The disk type must be ESDI, not SCSI, SCSI-2, MFM, IDE, etc. The
only models which Domain/OS supports are a few 76MB disks (Micropolis, ?),
Micropolis 1355 170MB, Maxtor 4380 380MB and the Maxtor XT-4380E 380MB
Fast Actuator disk. You cannot use the Maxtor XT-8760E 760MB disk with
the SMS/Omti controllers. I do not believe Domain/OS supports any
other disk types, although there may be a few other drives that work.
Contrary to Apollo's claims, you _can_ mix drive types when hanging
two disks off of one controller. That is, you can have a 170MB and a
380MB disk. There have been some claims that one or both of these
disks must be "Fast Actuators," but this is not true with the SMS/Omti
11914 controllers. Note: it is very important to check your SMS/Omti's
ROM revision; some of the older ones (revision B or less?) do NOT support
the 380MB disks. In addition, when replacing or adding a second disk,
you must make the proper jumper settings (see /ssr_util/systest/jumper).
If you have a WD7000V-ASE controller card on you DN[345]500, you are
in luck. The WD supports both the ESDI and SCSI storage interfaces
simultaneously (although you can disable one or the other). The ESDI
interface supports all disks that the SMS/Omti's support, in addition
to the Maxtor 8760E. The WD has the abillity to automatically
"recognize" what disk is connected, so no jumper settings for different
disks are required. Furthermore, you can have two WD's in one node,
expanding the total maximum ESDI disks capacity to over 2GB [if you do
this, the second controller _MUST_ have its SCSI interface disabled].
If you have SR10.4.0.xx or below, the SCSI interfance can only be used
with up to 7 non-disk storage devices, including CD-ROM, 4mm, 8mm, QIC,
9 track, optical, etc. If you have a non-SCSI tape/floppy already, you
cannot use the SCSI interface of the WD, so it _must_ be disabled.
If you have SR10.4.1 or above, the SCSI interface can also be used
with hard disks (see below).
The 8mm tape drives must be SCSI ids 1,2,3, or 4. These correspond to
devices rmts8, 9, 10, and 11 (12-14 for non-rewinding devices). Although
wbak is not officially supported on 8mm drives, it works fine at 10.3+ (and
at 10.2?). Use m0 for SCSI id 1, m1 for SCSI id 2, etc. There is a long
pause before it starts writing the tape with wbak. The tar and omniback
packages work just fine (as do lots of other vendors' backup packages, I'm
sure).
Domain/OS SR10.4.1 now supports SCSI disks (in addition to other SCSI
non-disk peripherals) on DNxxxx nodes with WD7000 controllers.
From the release notes:
SCSI hard disks are now supported on DN3500, DN4500, DN5500, and DN100x0
running Domain OS SR10.4.1. ... The supported SCSI disks are:
* C2217T Series 6000 Model 1350SE
* C2474T 1.3 Gbyte upgrade for the C2217T tower
[note: I would assume that most SCSI disks will work without problems.
if there are known incompatibilities, please let me know, and I will
include the info in the FAQ]
SCSI hard disks are supported through an external connection to the
Western Digital WD7000-ASC controller card. SCSI hard disks can be used
only in conjunction with a primary or boot ESDI hard disk and not
as the primary or boot disk.
The invol and salvol programs initializes the disk and are executed
on the SCSI hard disks after the OS is running. The stand-alone
sau utilities, invol, salvol, etc., do not support the SCSI hard disks.
Volume striping is supported across the SCSI disks. The maximum
volume size is 2GB on the DN3500 and DN4500, and 4GB on the DN5500.
The SCSI disks are accessed by invol, salvol, mtvol, etc., with the
names w2:0, w3:0, ..., w6:0 on the DN3500, DN4500, and DN5500; and
with the names w4:0, w5:0 and w6:0 on the DN100x0.
For info on turning an ESDI disk into an SCSI disk, see the section on
SALVAGING OLD APOLLOS.
For more information, consult the "disk-info" file available from
ftp://ftp.wfu.edu/usenet/apollo/doc/disk-info.
--( 8/30/94, John Thompson <thompson@pan.ssec.honeywell.com>,
Dave Ahn <ahn@hbar.phy.wfu.edu>,
Russell Ayling <rayling@xwdev.pandc.rta.oz.au> )--
--------------------------------------------------------------------
[5.2] I'm trying to get an SCSI-2 type disk to work with my Apollo, but it
doesn't seem to work. What did I do wrong?
--------------------------------------------------------------------
Apollos don't like to be hooked up to a SCSI-2 drive!
> These drives will work with 400's (and DN-2500's) if they are set to
> respond as SCSI-1 or SCSI-1/CCS devices. You need to execute the Change
> Definition SCSI command on the drive to change their response. Talk to
> your supplier and see if they will do this for you. (R Squared does this
> sort of thing all the time, besides (normally) providing manuals :-)
If you have a SCSI-2 drive that you want to put on a DN-2500 or HP/Apollo
9000/4xx system, and if INVOL doesn't like it (device xyz not recognized by
device driver), then the "mts" program may be used to execute the Change
Definition command for those drives that do not have jumpers to perform this
function. The mts program is available from the IWorks library system
archives, and the specific option is accessed through the "debug" command.
--( 2/15/94, Michael Lampi <lampi@mdlcorp.com> )
We are currently installing a DEC 5200 2 Gb disk which was SCSI-2 Using
mts got us atleast as far as running invol on it. Took quite a while to get
the baby formated, though. Only wonder is whether the change command is
permanent?
--( 2/15/94, Willem Jan Withagen <wjw@eb.ele.tue.nl> )
Try using /systest/ssr_util/scsi_info to check what info is returned from
the drive. It probably claims to a a SCSI-2 device ... in which case the
Domain/OS SCSI disk software is going to refuse to deal with the drive.
Many disks can be configured as either SCSI-1 or SCSI-2 depending on their
jumper settings.
--( 2/15/94, Dave Krowitz )
-----------------------------------------------------------
[5.3] Can I use Exabyte tape units on my Apollo?
Do I need to buy Omniback to use my Exabyte 8mm tape drive?
-----------------------------------------------------------
Yes, you can use Exabyte SCSI-1 EXB-8200 tape unit with the Apollo,
provided your Apollo has an SCSI interface (built-in or with WD7000V-ASE).
There is no need to create a device file, like /dev/exabyte, using the
/etc/mknod command. The device files already exist:
id devices wbak/rbak -dev
1 rmts8, rmts12 m0 (default)
2 rmts9, rmts13 m1
3 rmts10, rmts14 m2
4 rmts11, rmts15 m3
It is recommended that you rewind the tape before accessing it with:
mt /dev/rmts9 -scsi rewind
There are some problems with using the 8200 SX drives because of the length
of time it took to rewind, label, reposition, etc. A wbak label of the
tape fails. The 8200SX works with tar at SR10.4, but rwmt does not.
--( 3/28/93, Chris Folland, Jim Waldram <waldram@grizzly.uwyo.edu> )
Apollo's earlier tape utilities, including "wbak", "rbak", and "rwmt" access
the tape drive directly via calls to either the magtape driver or the
cartridge tape driver, depending on whether you use "-dev mt" (the default)
or "-dev ct". These calls are made via the unreleased "tfp_$" calls, which
then branch out to either the unreleased "mt_$" or the "ct_$" calls. All of
these library routines are in /lib/tfp. When Apollo introduced their 8mm
Exabyte drive, they wrote a new tape library to support the drive; and they
did *not* add support for the drive to the existing "tfp_$" library. Thus,
the older Apollo programs can not access Apollo's 8mm drive. Only programs
which use the new tape library can access the drive, and Omniback is the
only Apollo utility that I'm aware of which does use the new library.
The standard Unix utilities, such as "tar", "dd", "mt" and the like, all
access the tape drive via a Unix device file (eg. /dev/rmt0). As of SR10.x,
Apollo has supplied device files for SCSI tape drives attached to either
the native SCSI port of the DN2500 or the SCSI port of the multi-function
WD7000 disk controller used on most DN3500 and DN4500 machines. These
device files are /dev/rmts8 and /dev/rmts12 (rewind and no-rewind) for
SCSI tape device 0, and /dev/rmts9 and /dev/rmts13 (rewind and no-rewind)
for SCSI tape device 1 [note: hardware hackers, feel free to correct me!
this explanation is getting long enough to publish as an article -- I'd
*hate* to get this wrong in print!!]. These device files invoke the *new*
Apollo tape library, and therefore can access the 8mm Exabyte drive in
addition to SCSI cartridge tapes and SCSI 9-track tapes. The device files
/dev/rmt8 and /dev/rmt12, on the other hand, access the old tape library
for 9-track drives; and /dev/rct8 and /dev/rct12 access the old tape library
for non-SCSI cartridge tape drives.
Now, there *is* a way to use "wbak" and "rbak" with the 8mm Exabyte drive:
you use the "wbak -to" and "rbak -from" options to redirect I/O to a file
instead of old tape library, and you use either /dev/rmts8 or /dev/rmts12
as the file name. There is a minor drawback to this: the ANSI labeled tape
options such as "-fid" (file ID), "-vid" (volume ID), and "-f NN" (write to
the NNth file on the tape) won't work -- you can only write an unlabled file
to the current position on the tape.
So much for HP/Apollo ... There *is* at least one 3rd party vendor that
provides a cleaner solution. Workstation Solutions sells the Exabyte drive
packaged with a version of the *old* Apollo tape library that supports the
8mm drive, and a utility program that automatically loads this library prior
to running "wbak", "rbak", "rwmt", and any other program you like. The
library replaces the regular Apollo 9-track tape library and makes the
Exabyte drive look like the 9-track tape. Thus any program which uses the
"mts_$" and "ios_$" calls to access a 9-track tape will work ... and any
program which uses the /dev/rmt8 or /dev/rmt12 device files (which in turn,
access the old Apollo tape library) will also work.
Either way, your Apollo sales person is mis-informed. Exabyte drives *can*
be used on the Apollos under SR10 with DN2500/3500/4500 machines via the
SCSI tape device files; or under either SR9.7 or SR10 via either the magtape
library calls or the old, non-SCSI, device files with Workstation Solutions'
package on DN2500/3500/4500 with SCSI ports, or on DN3000/4000 machines
with an AT-BUS SCSI adaptor card.
--( 2/15/94, David Krowitz <krowitz@richter.mit.edu> )
MDL Corp. now has a driver for using Exabyte 8500's, 8200's, 8205's, etc.
under DomainOS 10.3.x and 10.4 with wbak, rbak, tar, etc., and supports
different densities, etc. as well as automatic byte-swap detection and
conversion on the fly for ANSI-labeled volumes (such as those made by wbak).
--( 2/9/93, Michael Lampi <lampi@mdlcorp.com> )
There exists a video8 backup-unit with a capacity of 2.2 Giga. The name of
the company who sold it was Cyber.. Data Group (don't kill me if the name`s
wrong, I can look it up if you're realy interested). We used it on a 425
with SCSI.
We used wbak/rbak. Note that there is a problem with wbak under SR10. You
can no longer overwrite a file-container > 1 without first overwriting all
previous file-containers.
--( 2/15/94, Frank Teusink <frankt@cwi.nl> )
-------------------------------------------------
[5.4] How can I read cartridges written on Sun systems?
-------------------------------------------------
APOLLO supports the new QIC 24 Tape Format only. Sun supports the (obsolete)
QIC 11 (default) and QIC 24 formats. Some older Suns do not support QIC 24.
If you write tar tapes on a Sun please use the QIC 24 format. This
corresponds to the Sun nrst8-11 devices, for instance the /dev/nrst8. For
more information, you may try 'man 4 intro' and 'man 4s st' on your Sun.
Then the archive can be read with the Apollo /dev/rct12 device.
Newer suns support still another (higher density) QIC 150 format. However
they still support QIC24, which is the only format supported on the Apollo.
--( 2/15/94, Harald Hanche-Olsen <hanche@imf.unit.no> )
Apollo 1/4" tapes are written as QIC-24 format (60 Mb per DC600A cartridge,
~45 Mb per DC300XLP cartridge). Sun-3's can read and write either QIC-11 or
QIC-24 tapes. Sun-4's (Sparcstations) can *read* QIC-24 tapes, but only
write QIC-120 (or is it QIC-150?) tapes. Apollo "tar" tapes are readable on
Suns, but with pre-SR10 tapes you may need to force the blocksize (if I can
remember back to SR9, I think the Apollos were using a blocking factor of
1?) to match.
--( 2/15/94, David Krowitz <krowitz@quake.mit.edu> )
---------------------------------------------------------------
[5.5] How can I use wbak to write stdout to a Sun workstation's tape?
---------------------------------------------------------------
I currently run SunOS 4.1.2 and SR 10.2.1. I rsh to the target machine and
run a csh script similar to the following:
on intr error
rm latest_backup_listing
(/com/wbak -stdout -full -l /whatever | rsh dump_machine \
dd of=/dev/nrst8 ibs=8192 obs=8192) >&! latest_backup_listing
if ($status > 0) then
rsh dump_machine touch ERROR.rdump.target_system
endif
exit
error:
rsh dump_machine touch ERROR.rdump.target_system
exit
although I have also tried (and my scripts optioally allow) the following:
rsh dump_machine "/com/wbak -stdout -full -l /whatever" | \
dd of=/dev/nrst8 ibs=8192 obs=8192
I have just completed a rather extensive backup package, written in Perl,
which may be used to backup Sun, Apollo, and SGI machines, and which
features an automated interactive restore facility. I would be willing to
make these available to you if you want to try them out.
--( 2/15/94, <rmallett@ccs.carleton.ca> )
----------------------------------------
[5.6] Can I use DAT drives to back up Apollos?
----------------------------------------
You can use them, but only with SR10.3.5 (= SR10.3 + PSKQ3_91); you can use
wbak/rbak, or tar, or whatever.
We got our DAT drive recently. /systest/ssr_util/scsi_info tells me it is
a Sony SDT-1020; the salesman sold it as a Sony 2GB drive. (It is a Sony
drive, packaged locally into a cabinet with a power supply.)
I tested the drive with 425t, DN2500, DN10000, DN3500; I cannot remember if
I tested it or not on DN4500 and DN5500 (the DN[3-5]xxx with Western Digital
controller, Apollo part number 12283; the DN10000 with the SCSI cartridge
controller, Apollo part number 12171). It worked without a hitch, as
described in /install/doc/apollo/pskq3_91.v.10.3__notes.
--( 2/15/94, Paul Szabo <szabo_p@maths.su.oz.au> )
----------------------------------------------------------
[5.7] How do I install an ethernet card in my Apollo DN[345]x00?
----------------------------------------------------------
This information is available by anonymous FTP at:
ftp.wfu.edu:/usenet/apollo/doc/ethernet.info
--( 3/4/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )
----------------------------------------------------
[5.8] Why does my DN10000 ethernet interface stop working?
----------------------------------------------------
The solution is the new Ethernet board (part no. A1658-66016, rev. F), plus
the OS/TCP patches from the 9109 or later patch tape. Note that there is a
second set of patches that are not on the 9109 tape, which you will
definitely need, and even those still have a problem with the "mbuf"s being
either all filled or not release properly (we are now having tcpd aborting
when it improperly frees a buffer). This is still under investigation by HP
(call # A2055392).
--( 2/15/94, Mike Peterson <system@alchemy.chem.utoronto.ca> )
-------------------------------------------------------------------
[5.9] Has anyone else experienced power-supply problems with their Apollo
DN10000?
-------------------------------------------------------------------
There is a SERVICE NOTE on the +5 V portion of the 10k power supplies dated
18 June 1990. A summary of the text follows:
DN100X0/DSP100X0 Serial Numbers: All
Date Code: All +5 Volt Booster Modules with 1988 Date Codes Performed By:
HP/Apollo Qualified Service Personnel Only Parts Required: +5 Volt, 150W
Control Module (APN 010524-001)
Situation: A problem has been identified with the DN100X0/DSP100X0 power
systems in both Manufacturing and the Field. The power system shuts down due
to a +5 Volt OV (Over Voltage) failure.
Having evaluated several Power EuroCards from Manufacturing and returns from
the field, R&D has identified an oscillation on some of the +5 Volt Booster
DC/DC Converters. This oscillation forces the +5V output voltage to exceed
+5.3V dc and the microprocessor shuts down the power system.
After having tested different +5 Volt Booster Module configurations, R&D has
concluded that Booster Modules with 1988 Datecodes are the direct cause of
the +5 Volt OV (overvoltage failures).
--( 2/15/94, JJW <waldram@grizzly.uwyo.edu> )
-----------------------------------------------------------------
[5.10] Why does my 8MB memory card work on a DN3500 but not in a DN4500?
-----------------------------------------------------------------
Chances are, your card is a general purpose memory board, not a page
mode memory board. The DN4500 and DN5500 have a redesigned memory
system (interleaved) which requires memory boards to be added in matching
pairs (two 4MB or two 8MB boards, but not one 4MB and one 8MB). Here is
the memory compatibility table from the manual "Installing Memory in the
Domain Personal Workstations and Servers," Order No. D-10615-0:
DS5500-.
DS3550,DS4500-. |
DS4000-. | |
DS3010A,DS3500(Except DS3550)-. | | |
DS3000(Except DS3010A)-. | | | |
| | | | |
Size Part No. V V V V V
--------------------------------------------------------
2MB(1) 008496 +
4MB(1) 011982 +
4MB(1) 013079 +
4MB(1) 010275 +
4MB(2) 013495 + +
4MB(2) 013480 + + +
8MB(1) 009988 +
8MB(1) 011983 +
8MB(1) 013078 +
8MB(2) 013496 + +
8MB(2) 013481 + + +
16MB(2) A1918-60001 +
(1) General Purpose Memory
(2) Page Mode Memory
Contrary to belief, the DN4000 does NOT have an interleaved memory system,
so you can mix and match boards. Although the above table lists the
"official" memory boards supported on various platforms, personal experience
has proved that any 4/8MB board which works in the DN4500 will also work in
the DN3500 and DN4000. Be careful when you use DN3500/4000 memory boards
in a DN4500. I've seen the boards work fine for a few days, even up to
a week, then result in a memory parity error and a systems crash.
--( 3/4/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )
--------------------------------------------------------
[5.11] What are the conections in a 3-way serial port splitter?
--------------------------------------------------------
Apollo 1 to 3 serial connector:
Sio 1 Sio 2 Sio 3
1 - 1 1 - 1 1 - 1
7 - 7 7 - 7 7 - 7
2 - 2 2 - 12 2 - 21
3 - 3 3 - 13 3 - 9
4 - 4 4 - 14 4 - 23
5 - 5 5 - 15 5 - 10
8 - 8 8 - 16 8 - 25
20 - 20 20 - 18 20 - 19
The left columns are the connections to the divided stream. The right
columns indicate the connection made in the joined connector which goes in
the Apollo's back.
--( 2/15/94, Willem Jan Withagen <wjw@ebh.eb.ele.tue.nl> )
--------------------------------------------------
[5.12] Can I add serial ports to DN[345]x00 nodes?
How about an internal modem?
Why does my Apollo look like it has an IBM AT bus?
Can I use PC ISA cards in my Apollo?
--------------------------------------------------
You can add serial ports with an SPE (Serial and Parallel Expansion)
card and the SPE software. The SPE card is actually just your standard
IBM-PC serial/parallel I/O card; chances are, you can salvage one from
an old PC and use it in the Apollo. You do, however, still need the
SPE software (actually just a bunch of drivers and device files) to
use the card. At least version 2.2 of SPE is REQUIRED for SR10.4;
earlier versions of SPE will work with SR10.1-3.
Apollo warns of input overrun errors when using the SPE ports at speeds
above 4800 baud. There is insufficient buffering on the card to support
these higher speeds, and you may loose data if the node is loaded. Faster
nodes should have fewer problems, but your mileage will vary. Consult the
release notes that come with the SPE software. This input overrun problem
IS NOT THE SAME as the buffer overrun problems with the SIO ports under
SR10.4 The latter problem can be solved by applying a patch.
Philip D. Pokorny has been able to get a STANDARD IBM-PC internal modem
to work in a DN3000. The SPE software is required to access the modem.
The modem must be configured at address 3f8, COM1, and interrupt 4, and
can be accessed thru the use of 'spe_tty_sio1_ddf.' The SPE software
installation will create TWO serial device descriptions in
/dev/global_devices, so you need to DELETE the one for SPE SIO2; this
device does not exist on your modem. Failing to do this will result in
an error message at boot time, stating that it was unable to initialize
the second serial device. In essence, what you're doing is fooling the
Apollo into thinking that the internal modem is an SPE card. Note that
the same buffer overrun problems exist with using the internal modem,
so you may not be able to use a high-speed (>9600 baud) modem.
As you may have guessed, the Apollo DN[345]xxx boxes have an AT bus.
Some of the boards used in the Apollo are bastardized PC cards (such
as the disk controllers, SPE card, 1280x1024 video card, etc; see
section on SALVAGING APOLLO PARTS for more info). This, however, does
not mean you can take any PC card and expect the Apollo to recognize it,
even if the card "fits." It is quite possible to write a device driver
for a PC card using the Apollo GPIO calls; if anyone writes one for the
Sound Blaster, please let me know! :)
--( 3/4/94, Philip D. Pokorny <philip@cel.cummins.com>,
Dave Ahn <ahn@hbar.phy.wfu.edu> )
Whether or not PC ISA cards can be used in an Apollo depends. Usually,
the answer is no. Most of the Apollo cards were designed specifically
for the Apollo, so they would be useless in PC's. Likewise, most PC
hardware isn't designed to be used in an Apollo, so while the card may
fit and the Apollo may boot fine, it won't be able to use it. There
are certain exceptions to this. For example, you can take a PC 3C505
16 bit ethernet card and use it in an Apollo (without the boot PROM),
and the same goes for a serial/parallel I/O card or an internal modem.
Theoretically, you can write drivers using GPIO routines so that the Apollo
can use the PC cards. However, I don't know of anyone who has done this.
See below for some info on GPIO, drivers and PC cards.
--( 7/26/94, Dave Ahn <ahn@hbar.phy.wfu.edu> )--
Writing device drivers with GPIO is pretty easy. The only problem is that
usually, non-trivial PC cards use on-card BIOS routines to hide the actual
IO going on. Since Apollos have a different CPU, and none of the other PC
assumptions hold either, the BIOS isn't much use. And ususally only these
BIOS routines are documented; the port IO isn't.
It took me several months to write a VGA device driver, only about two days
of which were actually writing the driver code. The rest was just figuring
out the blasted barely-documented port IO.
So before you buy a card, check the available documentation.
--( 3/22/94, Frederick Roeber, <roeber@vscrna.cern.ch> )--
------------------------------------------------
[5.13] What is the use of an ATR card in an HP9000/7xx?
------------------------------------------------
Actually, the ATR card used in Snakes is *exactly* (I know, I spec'd it)
the same one used in the old DPCI-Ring product. That means it's the same
board as used in the DN4XXX-series, but with the Aegis boot PROM removed
and a node ID inserted in the socket that was always there (way back in the
REAL old days, you couldn't even boot an Apollo node without a network card
in it because then it wouldn't have a node ID to generate UIDs from, but
somewhere along the line we got smart and started putting them on the
system board, but that's another story...).
As to IP encapsulation on ATR, Pete is right, the entire basic DDS header,
all *70* bytes of it, is there. It has to be or I'd have broken real Domain
nodes. Right after the DDS header is a little 12 byte header called the DR
header that Domain TCP uses for its own purposes. After that comes a
conventional IP packet.
I *didn't* port DDS to HP-UX in order to get ATR support into it. That
would have been an extremely time-consuming effort with very little payoff.
What I did do is put enough support in the driver to be able to answer
lcnode (ask_who, ask_who_notopo, and ask_rem_who) requests, as well as
ask_time, ask_bldt, ask_diskless, and ask_node_root. lcnode I *had* to
support. If I didn't, I'd again break the existing rings these nodes were
destined to go in to. The rest I put in because of the following scenario,
which in my opinion is very common:
1) lcnode
long list returned including some uncataloged nodes
2) bdlt -n NNNNN
where NNNNN is some uncataloged node's node id
in this case, it turns out to be an HP-UX node, so we
return the same string which would be returned by a
'uname -a' command
3) ctnode foobar NNNNN -root
this puts the node into the Domain NS Helper database
the next time it is queried with an lcnode
I attempted to violate the "Principle of Least Astonishment" as little as
possible, but as Pete put it, we are "a little bit pregnant." There are
places where this scheme breaks down, such as the 'lcnode -from' command
when run from the other side of a Domain router or when the Domain Automount
Daemon (damd) tries to make an NFS mount point in the network root for a
node that's already been cataloged this way, but I figure it's still better
than a poke in the eye with a sharp stick. ATR on HP-UX is only intended to
help customers transition from Domain on ATR to HP-UX on a better network,
either FDDI or Ethernet (let's please not have a religious argument about
how Ethernet isn't a better network than ATR; the market has already decided
that one...), not to be used as the core network of new installations.
--( 2/15/94, Carl Davidson <ced@apollo.hp.com>,
Herb Peyerl <hpeyerl@novatel.cuc.ab.ca>,
Peter E. Giza <giza@apollo.hp.com> )
--------------------------------------------------
[5.14] My 19" monochrome monitor flickers. What can I do?
--------------------------------------------------
Subject:
Apollo Domain 19 inch B&W monitor horizontal drift and frequency
vistability.
Problem Component:
Capacitor C207, a frequency determining element in the horizontal
oscillator circuit IC202. This circuit uses a NE555 I.C. in an astable
multivibrator configuration. The original component was a polystrene
type capacitor which demonstrated a pronounced negative temperature
coeficient.
Fix:
Replace C207 with either a mylar film or a dipped mica 1000pF capacitor.
The oscillator circuit has a fairly narrow range of adjustment such that
selection or trimming of value may be necessary. The total value of the
replacement capacitor in this case was 1195 pF (1140pF in another).
Procedure:
Set the horizontal frequency control to mid range. Connect a frequency
counter to pin 3 of IC202 and select or trim the value of C207 until the
oscillator hasa free running frequency of 68.219KHz. Free running
operation occurs with the 9 pin computer connect cable is disconnected.
After obtaining the desired frequency, reconnect the computer cable. The
horizontal oscillator should lock immediately. Adjust the horizontal
frequency control through its entire range. The oscillator should stay
locked throughout most if not all the potentiometer range of adjustment.
If drift in horizontal position occurs, it may be due to the polystyrene
capacitor C202 used with IC201 the horizontal positioning one shot
multivibrator. Its value is also 1000pF and should be replaced with a
mylar or dipped mica type capacitor.
--( 2/15/94, Ricky Houghton <houghton@iuvax.cs.indiana.edu> )
--
Dave Ahn Internet: ahn@hbar.phy.wfu.edu, ahn@wfu.edu
#include <stdisclaimer.h>
"When you were born you cried, and the world rejoiced. Try to live your life
so that when you die you will rejoice, and the world will cry." -1/2 jj^2